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SOME HISTORIC MOMENTS IN NETWORKING 

While awaiting the completion of an interim network control 
program (INCH) for the MIT MAC Dynamic Mode 1 i n g / Conpu t e r Graphics 
PUP-6/10 System (MITDG), we were able to achi eve a number of 
'historic moments in networking' worthy oT some comment. First, 
we were able to connect an MITDO terminal to a Multics process 
making it a Multics terminal. Second, we sticcessfu1 1v attached 
an MITDG terminal to the Harvard PDP-10 System thereby enabling 
automatic remote use of the Harvard System for MIT. Third, wo 
developed primitive mechanisms through which remotely generated 
programs and data could be transmitted to our system, «xecutod, 
and returned. Using these mechanisms in rlos n cooperation with 
Harvard, we received graphics programs and 3D data from Harvard's 
PUP-10, processed them repeatedly using our Evans A Sutherland 
Line Drawing System (the E&S), and transmitted 2D scope data to 
Harvard's PDP-1 for display. 

The I I NCR 

Our experiments were run on the MITDG PDP-6/10 using what we 
have affectionately called our 'interim Interim NCP' (IIMCP). 
Under the IIMCR the IMP Interface is treated as a single-user I/O 
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device which deals in raw network messages. The software 
supporting necessary system calls includes little more t K an th" 
basic i nterrupt-hand 1 ing and buffering schemps to be used latT 
by the NCP. In short, the user-1 eve 1 programs which brought us 
to our historic moments were written close to th^ birdwarf w i t h 
full knowledge of IMP-HOST Protocol (BBN 1822). When t^o INCP 
and NCP are completed, th°se programs can bo orun^H considerably 
(80"'). The exercise of writing urograms which conform to 
IMP-HOST Protocol was not at all v/asted. Only now can those of 
us who are not writing the NCP begin to grasp the full meaning of 
RFNM's and their use in flow control. The Penalties for ignoring 
an impatient IMP, for failing to send NOOPS (NO-OPS) when 
starting up, and for blasting data onto the Network without 
regard for RFNM's are now well understood. 

The Multics Connection 

Our quest for historic moments began with the no<--d t.n 
demonstrate that the complex hardware-software system separating 
MITDG and Multics was operative and understood. A task force 
(Messrs. Bingham, Brodie, Knight, Metcalfe, Meyer, Padlioshy and 
Skinner) was commissioned to establish a 'polite conversation' 
be tween a Multics terminal and an MITDG terminal. 

It was agreed that messages would be what we call 'network 
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ASCII messages 1 : 7-bit ASCII char-actors r i a h t-a d j u s t o J in S-bit 
fields having the most significant hit sot, narkinr,, and madding. 
In that Multics is presently predisposed toward line-oriented 
half-duplex terminals, it wtis decided that all t ran s.m i s s i on s 
would end with the Multics EOL character (ASCII <I.INF FEFD>). To 
avoir! duplicating much of the INCP in our experiment, the PDP-10 
side of the connection was freed by convention from arbitrary 
bit-stream concatenation requirements and was permitted to 
associate logical message boundaries with. network message 
boundaries (sic). The 'polite conversation' was thus established 
and successful. 

Multics, then, connected the conversation to its command 
processor and the PDP-10 terminal suddenly became a Multics 
terminal. But, not quite: 

First, in the resulting MITDG-Mu 1tics connection there was 
no provision for a remote QUIT, which in Multics is not an ASCII 
character. This is a problem for Multics. It would seem that an 
ASCII character or the network's own interrupt control message 
could be given QUIT significance. 

Second, our initial driver program did not provide for 
RUBOUT. Because the Multics network input stream bypassed the 
typewriter device interface nodule (TTYMIM), linn 
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canonica1ization v/as not porfornnd, In a more ^lep.ant 
i nip 1 emen ta t i on , line canon i ca 1 i za t i on could hr* Hone at Multics, 
providing the type-in editing conventions fani1iar to Multics 
users. We fixed this prohlnn hastily by havinr our 'river 
program do local RUBOUT editing during line assenhlv, t h us 
providing type-in editing conventions familiar to MITDG users. 
It is clearly possible to do both local Lyoe-in editing an-' 
distant-host type-in editing. 

Third, we found that because o f the manner in whic h our 
type-in entered the Multics system under the current network 
interface (i.e. not through TTYDIM), our remotely controlled 
processes were classified 'non-inLeractive 1 and thus fell to the 
bottom of Multics queues giving us slow response. This problem 
can be easily fixed. 

The Harvard Connection 

Connecting MITDG terminals to Multics nroved to easy in 
that the character-oripnte ,( MITDG system easily assembled lines 
for the Multics 1ine-oriented svstem. We (Messrs. Darker, 
Metcalfe) decided, therefore, that it would he worthwhile to 
connect the MITDG system to another c r a c t e r-o r i en t e d system, 
namely Harvard's PDP-10. This move was also motivated by MlTDG's 
desire to learn more about Harvard's n°w laneuagp systems via 
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canonica 1 i za t i on was not performed. In a no re elegant 
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SQMF HISTORIC MOMENTS IN NETWORKING 

While awaiting the completion of an interim network control 
program (INCP) for the MIT MAC Oynanic Mode 1 i ng/Compti t e r Grannies 
PDP-6/10 System (MITDG), we were able to achieve a number of 
'historic moments in networking' worthy of some comment. First, 
we were able to connect an MITOG terminal to a Multics nrocess 
making it a Multics terminal. Second, we siiccessfu11v attached 
an MITDG terminal to the Harvard PDP-10 System tberehy enabling 
automatic remote use of the Harvard System for MIT. Third, we 
developed primitive mechanisms through which remotely generate^ 
programs and data could be transmitted to our system, executed, 
and returned. Using these mechanisms in clns° cooperation witf 
11 u ,.,o ronoiv/oj rrnnhics i > r o r r a m s and 3D data from Harvard's 
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compatible and connected. But not quite: 

First, Harvard runs the Digital Equipment Corporation (DEC) 
time-sharing system on their PDP-10 which has <control-C> as a 
QUIT character and <control-Z> as an end-of-file (EOF). MITDG 
runs the MAC Incompatible Time-sharing System (ITS) which has 
<control-Z> as a QUIT character and <control-C> as an EOF. This 
control character mismatch is convenient in the sense that tyninp 
<control-C> while connected to Harvard system through MITDG 
causes the right thing to happen - caus°s the execution of 
programs at Harvard to QUIT, as opposed to causing the driver 
program at MITDO to QUIT. If, however, a Harvard program were to 
require that an EOF be typed, typing <control-Z> woul H cause ITS 
to stop the driver program in its tracks, leaving the Harvard EOF 
wait unsatisfied and the MITDG-Harvard connection severed. 

Second, the Harvard system has temporarily implemented this 
remote network console interface feature using a DEC style 
pseudo-teletype (PTY). This device vis-a-vis the DEC svstem 
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behaves as a half-duplex terriinal whTcIi wakes up on a set of 
'break characters' (e.g., return, alt mode) affording us an 
opportunity for an interesting experiment. The use of DDT 
(Dynamic Debugging Tool) is thereby restricted (though not 
prevented) in that break characters must be scattered throughout 
a DDT interaction to bring the PTY to life to cause DDT to do t ho 
right thing. For example, to examine the contents n' a core 
location one needs to type 'addr/<a1tmode> 1 (address slas h 
altmode) the altmode being only a ca11 -to-act i on to the PTY. To 
alter the contents of the opened location, one must then type 
' <rub-out>contents<return>'; the <rub-out> character delates the 
previous action <alt-mode>, the contents are stashed in the open 
address, and the <return> signals the close of the address and 
PTY wake-up. It would seem that DDT is a program that will 
separate the men from the boys in networking. 

Third, it was found that the response from the Harvard 
system at MITDG was seeemingly as fast as could lie expected from 
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The Harvard-MIT Graphics Experiment 

At Harvard are a PDP-1C T i me - s ha r i ng System and a grannies 
oriented PDP-1 / both connected to Harvard's IMP. At MITDG are a 
PDP-6/10 Tine-sharing System and an E&S Line Drawing System. It 
was felt (Messrs. Barker, Cohen, McQuillan, Metcalfe, and Taft) 
that the time had come to demonstrate that the network coul-i make 
remote resources available - to rive Harvard access to the FftS at 
MITDG via the network. The protocol for such use of the network 
was as follows: (1) MITDG starts its network monitor program 

listening. (2) Harvard starts its PDP-10 transmitting a core 
image containing an arbitrary PDP-10 program (with an embedded 
EfrS program in this case). (3) MITDG receives the core image 
from Harvard and places it in its memory at the starting address 
specified, collecting messages and concatenating them 

appropriately. (There was no word-length mismatch nrohl°m.) 
(4) Upon collecting a complete image (word count sent fi.rst along 
with starting address), MITDG stashes its own return address in a 
specified location of the transmitted orngram's image and 
transfers control to another image location. (5) Upon getting 
control at MITDG, the transmitted program executes (in this case 
sets up and runs an E&S program) and before returning to thn 
MITDG network monitor stashes in specified locations of its image 


7 



NETWORK WORKING GROUP 
REQUEST FOR COMMENTS #39 
iiir 569 7 


BOB iF TC A L T E 
19 JAN 1971 


the beginning and ending addresses of its results. (6) With 
control returned, the MITDG monitor prog ram then transmits the 
results to a listening host which makes good use of them (in this 
case a PDF-1 which displays them.). (7) Then the MITDG program 
either terminates, returns control hack to the image (as in this 
case), or waits for more data and/or program. The protocol was 
implemented in the hosts and used to run a Harvard-ass^mh1nd 
version of the EftS Aircraft Carrier Program (written originally 
by Harvard's Prof. Cohen) at MITDG and to display the resulting 
dynamic display on Harvard's PDP-1 driven DEC scopes. The 
Carrier Program was 'flown' from MITDG and the changing views 
thus generated appeared both at MITDG and Harvard. Thp picture 
was observed to change (being transmission limited) on the order 
of twice each second (porhans less often). Rut all was not 
rosey : 

First, it 'was observed that during the experiment prompting 
messages to the 1MP-Te1°types were often garbled. Most of the 
garbling can be attributed to the ASR-33 itself, some cannot. 
There were no errors detected during data trasmissions not 
involving the IMP-Teletypes. 

Second, during attemots to fly the Carrier from Harvard, we 
stumbled across a yet undiagnosed intermittent malfunction of 
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(presumably) the MITDG hardware and/or software which caused our 
network connection to be totally shut down by the system rlurinr 
by-directional transmission. This oroblem is currently under 
investigation. 

Third, the response of the total system was slow compared to 
that required to do real-time dynamic graphics. One would expect 
that if this limitation is to be overcome, higher bandwidth 
transmission lines, faster host response to network messages, 
and/or perhaps a message priority svsten will he required. 

General Comments 

In producing 'network. ASCII messages' we were required to 
bend over backwards to insert narking so that our last data hit 
could fall on a word boundary. Surely there must hp a fetter 
way. The double padding scheme and its variants with or without 
marking should be considered. Given thp current hardware, it 
would seem that double padding with marking would he an 
improvement. A sinple(?) fix to host IMP interfaces enabling 
them to send only good data from a nartially filled last word 
would permit a further improvement: marking and host-supo1ied 
single padding. 

In these initial experiments Harvard used the IMP-Teletyne 
message convention or what we call 'IMP ASCII messages' (without 
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narking) because it would allow them to use IMP-Te1etypes Tor 
logging in and testing. Multics, on the other hand, used the 
standard network message format (with marking) to have Host-Host 
compatibility as per accepted protocols. Both approaches have 
merit. The IMP-Teletype message format should be changed to 
conform with the network standard - it should have marking. 

Finally, we would like to announce our readiness to 
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